BPB metric bug: space bytes double-counted (inherited from closed parent PR #1545)

The decompressed train_gpt.py in this PR contains the same build_sentencepiece_luts bug that @SPThole identified in PR #1545, and which @Abhishek8108 acknowledged when closing that PR ("The corrected BPB is ~1.18, not 1.028").

Bugged code in this PR (decompressed from the LZMA self-extractor):

# build_sentencepiece_luts, around line 217
if piece.startswith("▁"):
    has_space[i] = True
    base_bytes[i] = len(piece[1:].encode("utf-8")) + 1   # +1 adds the space byte

Then the eval loop adds the same space byte again:

tb += (has_leading_space_lut[tgt] & ~is_boundary_token_lut[prev]).to(torch.float64)

Reference implementation (train_gpt.py at repo root, lines 186–189):

piece = sp.id_to_piece(token_id)
if piece.startswith("▁"):
    has_leading_space_np[token_id] = True
    piece = piece[1:]                       # strip ▁
base_bytes_np[token_id] = len(piece.encode("utf-8"))   # NO +1 here

The reference counts the space byte exactly once (in the eval loop, conditioned on ~is_boundary_token_lut[prev]). The bugged version counts it in both places for every ▁-prefixed token, inflating the byte denominator and deflating the reported BPB.

Running the parent PR's corrected LUT on the same checkpoint lands in the ~1.16–1.18 range (per @Abhishek8108's own correction on #1545), not 1.01671.

Bug was missed here because the training code is wrapped in an LZMA self-extractor, which hides it from standard review. Suggest the maintainers decompress and re-score before this shifts the leaderboard.